System and Method for Establishment of Rules Governing Child Accounts

ABSTRACT

A system and method for establishment of rules governing child accounts may include associating, in a database, a first transaction card through which access to monetary funds is extended with a second transaction card through which access to said monetary funds is extended. Also, in said database, said second transaction card is associated with one or more rules governing access to said monetary funds by said second transaction card. Finally, an individual owning said first transaction card is permitted to specify said rules governing access to said monetary funds by said second transaction card.

RELATED APPLICATIONS

This application is a continuation of and claims priority to U.S. patentapplication Ser. No. 11/487,169, entitled “SYSTEM AND METHOD FORESTABLISHMENT OF RULES GOVERNING CHILD ACCOUNTS,” filed Jul. 14, 2006,which claims priority to U.S. Provisional Patent Application Ser. No.60/700,049, entitled “SYSTEM AND METHOD FOR NEW EXECUTION AND MANAGEMENTOF CREDIT TRANSACTIONS,” filed Jul. 15, 2005. Both of these applicationsare incorporated herein by reference in their entirety.

TECHNICAL FIELD

The present invention relates generally to the field of financial anddata transaction systems, and more particularly to a system and methodof executing financial and data transactions over an open network.

BACKGROUND

FIG. 1 depicts a typical credit card transaction, as it is presentlycarried out. As represented in FIG. 1, the process begins with a creditcard holder 100 providing his credit card to an attendant located at apoint-of-sale device (e.g., cash register) within a merchant setting102, as represented by operation 101. In response, the attendanttypically “swipes” the card through a magnetic strip reader that iscoupled to the point-of-sale device. Thus, cardholder information,including the name of the cardholder and the credit card number, istransferred from the storage medium on the card to the point-of-saledevice.

The point-of-sale device combines the cardholder information withtransaction information (including total price of sale and merchantidentification), and sends the combined data set to an acquirer orthird-party processor 104, as represented by operation 103. Thethird-party processor 104 responds by forwarding the data set to thecard association's (e.g., Visa, American Express, etc.) proprietarytransaction network 106 (operation 105), whereby the data set is routedto the issuing bank 108, as shown in operation 107.

Upon reception of the data set, the issuing bank 108 checks the proposedfinancial transaction against a set of credit rules and either approvesor denies the financial transaction. If approved, the approval traversesthe identical path, in reverse sequence, (operations 109, 111 and 113)to reach the point-of-sale device at the merchant location 102.Thereafter, the card-issuing bank 108 forwards a monetary sum equal tothe sale price to the merchant's bank 110 by way of a similarly complexset of data transactions, as represented by operation 115 (typically, aprocessor is used as an intermediary that forwards the monetary sum tothe merchant's bank 110). At the expiration of the billing period, thecardholder 100 pays the sales price (plus interest and finance charges)to the card-issuing bank 108 (operation 117).

The aforementioned scheme exhibits certain shortcomings. For example, byvirtue of using a proprietary network to communicate data between themerchant 102 and the authorizing entity (the card-issuing bank 108, inthis case), expense is incurred in the establishment and maintenance ofthat network. This expense is ultimately borne by the merchant 102.Another disadvantage of the use of a proprietary network is thatrelatively small amounts of data can be transmitted from the merchant'spoint-of-sale device, due to infrastructural and cost limitations. Thismeans, for example, that the cardholder cannot be presented withdetailed information regarding a given transaction in his monthlystatement. In certain circumstance, existing credit card technologies doprovide for occasional inclusion of information concerning the contentof a given transaction. However, such information is not gathered at apoint in time that is contemporaneous with execution of the transaction.It is, instead, gathered well after the execution of the transaction.Given this delay in gathering data, certain advances presented hereinare presently not possible in the context of presently existing creditcard technologies.

Other shortcomings also inhere in the aforementioned scheme. Personalidentification information is typically both printed or embossed on thecredit card and encoded on its magnetic strip. This necessitates a delaybetween the point in time at which a credit card applicant is approvedfor a credit card and the point in time at which the applicant mayreceive the credit card (the applicant's personal information is printedand encoded on the card in the intervening period). Additionally,because the storage mechanism used by credit cards is a magnetic strip,a magnetic strip reader must be interfaced with the point-of-saledevice. This generates additional expense, which has the tendency todiscourage small businesses from accepting such credit cards.Furthermore, there presently exists a movement afoot to introduce radiofrequency identification (RFID) devices into credit cards. Such aninitiative also involves significant infrastructural investment, which,again, has the tendency to discourage small businesses from acceptingsuch credit cards.

SUMMARY

According to one embodiment, a computerized method may includeassociating, in a database, a first transaction card through whichaccess to monetary funds is extended with a second transaction cardthrough which access to said monetary funds is extended. Also, in saiddatabase, said second transaction card is associated with one or morerules governing access to said monetary funds by said second transactioncard. Finally, an individual owning said first transaction card ispermitted to specify said rules governing access to said monetary fundsby said second transaction card.

According to another embodiment, a system includes a first transactioncard through which access to monetary funds is extended and a secondtransaction card through which access to said monetary funds isextended. The system also includes a database in which said firsttransaction card is associated with said second transaction card, and inwhich said second transaction card is associated with one or more rulesgoverning access to said monetary funds by said second transaction card.Further, the system includes a computing system programmed to permit anindividual owning said first transaction card to specify said rulesgoverning access to said monetary funds by said second transaction card.

According to another embodiment, a computerized method includesassigning a first card number to a first transaction card through whichaccess to monetary funds is extended. The method also includes assigninga second card number to a second transaction card through which accessto monetary funds is extended, wherein said second card number isdifferent from said first card number. Finally, in a database, saidfirst transaction card is associated with said second transaction card,so that said monetary funds accessed through said second transactioncard are the same monetary funds as those accessed through said firsttransaction card.

According to yet another embodiment, a system includes a firsttransaction card through which access to monetary funds is extended,said first transaction card having a storage medium encoding a firstnumber uniquely identifying said first transaction card. The system alsoincludes a second transaction card through which access to monetaryfunds is extended, said second transaction card having a storage mediumencoding a second number uniquely identifying said second transactioncard. Finally, the system includes a database associating said firsttransaction card with said second transaction card, so that saidmonetary funds accessed through said second transaction card are thesame monetary funds as those accessed through said first transactioncard.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a typical credit card transaction.

FIG. 2 depicts a credit card transaction, according to one embodiment ofthe present invention.

FIG. 3 depicts a method by which a transaction card may be activatedalmost simultaneously with the point in time at which an applicationassociated therewith is approved.

FIG. 4 depicts an exemplary network environment in which the kernel ofFIG. 5 may be deployed.

FIG. 5 depicts an exemplary embodiment of a kernel that may be deployedin the exemplary network embodiment of FIG. 4.

FIG. 6 depicts an exemplary embodiment of a message communicated fromthe kernel of FIG. 5 to the software system of FIG. 7.

FIG. 7 depicts an exemplary embodiment of a software system that may beexecuted by one or more servers operated by a transaction platform.

FIG. 8 depicts an exemplary embodiment of a schema implemented by thedatabase of FIG. 7.

FIG. 9 depicts an exemplary embodiment of a message communicated fromthe software system of FIG. 7 to the kernel of FIG. 5.

FIG. 10 depicts an exemplary embodiment of a message communicated fromthe kernel of FIG. 5 to the software system of FIG. 7.

FIG. 11 depicts an exemplary embodiment of a method for rewarding acardholder for distributing anonymous, unassigned cards to prospectiveapplicants.

FIG. 12 depicts an exemplary embodiment of a method for permittingdispute of a cost associated with an item within a transaction.

FIG. 13 depicts an exemplary embodiment of a method for establishing orchanging rules governing use of a child card.

FIG. 14 depicts an exemplary embodiment of a method for establishing orchanging user-selectable fraud detection rules.

FIG. 15 depicts an exemplary embodiment of a method for establishing orchanging user-selectable algorithmic PIN modification rules.

FIG. 16 depicts an exemplary embodiment of a scheme for permittinginter-merchant exchange of goods.

FIG. 17 depicts an exemplary embodiment of a person-to-person exchangeof funds.

FIG. 18 depicts another exemplary embodiment of a person-to-personexchange of funds.

DETAILED DESCRIPTION

Various embodiments presented herein will be described in detail withreference to the drawings, wherein like reference numerals representlike parts and assemblies throughout the several views. Reference tovarious embodiments should not be construed as limiting the scope ofcovered subject matter, which is limited only by the scope of the claimsattached hereto. Additionally, any examples set forth in thisspecification are not intended to be limiting and merely set forth someof the many possible embodiments.

FIG. 2 depicts a financial transaction, e.g., credit card transaction,debit card transaction, stored value card transaction, pre-paid cardtransaction, etc., according to one embodiment of the present invention.As shown in FIG. 2, a cardholder 200 initiates the transaction bypresenting a credit card to a point-of-sale device 202 or to anattendant operating such a device 202 (operation 201). Of course, thetransaction may be initiated in the course of an ordinary on-linetransaction, such as by virtue of entry of cardholder information into aweb site designed for on-line commerce. For the sake of illustrationonly, the transaction as described with reference to the figures hereinis described as occurring at a point-of-sale device (at a merchantstore) manned by an attendant. Also, the card may be referred to hereinas a “credit card,” “card,” or “transaction card” for the sake offamiliar reference. In fact, as discussed below, the card may operate asa credit card, a debit card, a stored value card, and/or a data accesscard that permits access to various forms of data, such as health caredata, club membership data, etc.

The card may exhibit the following characteristics. The card, itself,may include a substrate (i.e., the body of the card), which may bepolymeric or of any suitable material. A storage medium may be disposedupon, embedded within and/or printed upon the substrate. The storagemedium may be read-only, such as a bar code printed upon the substrate,or may be readable and writable, such as a magnetic storage medium(e.g., magnetic strip). According to some embodiments, the credit cardmay have both a bar code and a magnetic strip thereon. According to someembodiments, a card number uniquely identifying the card is encoded uponthe magnetic strip and/or upon the bar code. Also, the credit card mayinclude an RFID device having a card number stored therein. According toone embodiment, the storage medium, whether it be a bar code, magneticstrip, or RFID device contains, encodes, and/or stores no personalinformation concerning the cardholder. According to some embodiments,the storage medium(s) on the card encodes, contains, and/or stores onlya card number uniquely identifying the card. According to someembodiments, the storage medium(s) of the card contains, encodes, and/orstores no personal identification number (PIN).

Upon receiving the card, the attendant provides the card to an inputdevice, such as a bar code reading device, magnetic strip reader, orRFID transceiver. The information encoded on the storage medium of thecredit card is then read. Next, the cardholder may be prompted for apersonal identification number (PIN), which may be entered into thepoint-of-sale device, either by the cardholder or by the attendant,through an appropriate input device, such as a keypad, keyboard, atouch-screen display, and/or any device suitable for entry of a PIN. Thedata from the credit card, the PIN, and transaction information from thepoint-of-sale device are used to populate a plurality of data packets,which may be “packaged” as a single unit that constitutes a request forauthorization of a proposed transaction. The various packets arediscussed in more detail herein, below. The packaged unit is encryptedaccording to a scheme generally described below, and is transmittedacross an open network, such as the Internet, to the transactionplatform 204, as shown in operation 203.

As described in greater detail herein, the transaction platform 204 maymaintain a degree of integration with the card-issuing bank, so as to beable to authorize or deny all, most, or some transactions (e.g.,transactions less than a threshold dollar amount), without necessitatingfurther communication to the card-issuing bank to arrive at anauthorization decision. After arriving at an authorization or denialdecision, the authorization/denial is returned via the open network(e.g., the Internet) to the merchant 202, as shown in operation 205.

The above-described embodiments exhibit certain advantages that are ofnote, but are not essential for practice of the various embodimentsdescribed herein. For example, communication between the merchant 202and the transaction platform 204 occurs via an open network, such as theInternet. By making use of an open network, the need for proprietarynetwork elements and/or lines is eliminated and/or reduced, meaning thatthe cost of executing each transaction is reduced. Also, becausecommunication via an open network such as the Internet is free ofcharge, a relatively greater quantity of data may be exchanged betweenthe merchant 202 and the transaction platform 204, allowing for greaterresolution in billing statements, as described below. Moreover, theadministration of bank rules as defined by a bank, such as availablecredit, interest charges and fees are managed by the platform, reducingthe need for constant communication between the information association202 and the various card-issuing banks 206, which is conducted throughscheduled system consolidation/synchronization, which may also beconducted via the open network, thereby reaping the same benefits.

Also of note is that, in some embodiments, the credit card contains nopersonal information. Specifically, no personal information is printed,embossed, or otherwise presented on the face of the card (e.g., the carddoes not bear the name of the cardholder), nor is personal informationencoded upon, stored within, or contained in the storage medium on thecard. This arrangement permits near-instantaneous placement of anactivated transaction card in the hands of a would-be cardholder. Forexample, as shown in FIG. 3, a supply of unassigned, anonymous cards maybe provided at, for example, a point-of-sale device at a merchant store(operation 300). By “anonymous,” it is meant that the card contains,encodes, and/or stores no information identifying an individual to whomthe card belongs. In other words, it does not bear the name of anindividual on its surface, nor does it have the name or otheridentifying information concerning an individual stored or encoded on astorage medium of the card. The storage medium of the card may containonly a card number that uniquely identifies the card, not the accountnumber.

As shown in operation 302, an anonymous card is distributed to anapplicant. This may occur, for example, at a point in time at which acustomer is about to transact a purchase of a good or service. Assumingthat a source of unassigned, anonymous cards is maintained at apoint-of-sale device, an attendant thereat may ask a customer if he orshe would like to apply for a credit card or open a pre-paid/storedvalue card. If the customer answers in the affirmative, then theattendant may supply the customer with a card. Of course, a would-beapplicant may obtain an anonymous card from any source, including fromfriends or other cardholders (discussed below).

Next, the transaction platform's server (discussed in detail, below) isprovided with the applicant's application information and the cardnumber uniquely identifying the card (operation 304). Assuming onceagain that the anonymous card is distributed to a customer at apoint-of-sale device, the customer's application information may beentered by the attendant into the point-of-sale device, whereupon it iscommunicated via a network, such as the Internet or telephone network,to the transaction platform's server. Additionally, the applicationinformation may be received by an employee of the transaction platform(e.g., via a telephone call with the applicant), and may be entered intothe server by the employee (or may be entered into a computer incommunication with the server). Still further, the applicant may bedirected to a web page or an in-store kiosk (e.g., the card may bear theweb address of a web page) that is structured to permit entry ofapplication information. The applicant may directly enter his or herapplication information into the web page, thereby communicating his orher application information to the server. In general, the applicationinformation may be received by the server in any manner.

The application information, itself, may include the informationtypically necessary to conduct a credit check, in order to determine thecredit worthiness of an individual. For example, such information mayinclude identifying information, such as the name, address, telephonenumber, and/or social security number of the applicant, and may alsoinclude employment information such as place of business, number ofyears worked at such place of business, etc. The application informationmay constitute a minimal set of information needed for the server toproperly handle financial transactions for the applicant. According tosome embodiments, the server has access to a database that may store awide variety of information concerning the applicant. Such informationmay include health information, emergency contact information, familyinformation, etc. (these other forms of information are discussedbelow). At the time that the application information is received, theaforementioned other forms of information may not be received by thetransaction platform's server. Thus, the server uses the applicationinformation to populate one or more tables in the aforementioneddatabase relating to the applicant's application, and also minimallypopulates other tables relating to the applicant and to other matters.If the application is ultimately approved, other types of informationmay be collected from the applicant/cardholder at a later time, and thevarious tables of the database may be more fully populated.

After receiving the application information, the server entersinformation in the database to associate the applicant's card numberwith the applicant's application information (operation 306).Thereafter, an evaluation of the application is performed (operation308). According to some embodiments, a credit check may be performedupon the applicant. The application information may include a sufficientquantity of information to query a credit score service (example: FairIssaac Co.) to obtain a credit score for the individual (example: FICOscore). For example, the information association's server maycommunicate, via a network such as the Internet, with a credit scoreservice to determine a credit score associated with an individual. Ifthe credit score exceeds a particular threshold, then the application isapproved, otherwise it is declined. According to other embodiments, theapplicant's application information is communicated via a network suchas the Internet to one or more card-issuing banks. Each card-issuingbank individually uses the application information to perform their ownanalysis and independently conclude whether to deny or approve theapplication. According to some embodiments, the transaction platform'sserver compares the credit terms offered by the approving card issuingbanks, and selects the card-issuing bank offering the best credit termsas the bank associated with the card number. According to otherembodiments, each card-issuing bank may communicate a bid, e.g., amonetary sum it is willing to pay to the transaction platform to acquirethe account, and the transaction platform may select the bank offeringthe highest bid, for example. According to other embodiments, more thanone bank may be associated with the card number, and theapplicant/future cardholder is permitted to select from among the banksfor extension of credit, with each purchase.

Irrespective of how the analysis is conducted, if the evaluationindicates that the application is approved, then the server entersinformation into the database to associate rules with the applicant'scard, as shown in operation 310. For example, a spending limitdetermined based upon the credit score may be associated with the card(or, the card-issuing bank may determine the limit and communicate thelimit to the transaction platform's bank), generic anti-fraud data mayalso be associated with the card, etc. (operation 312). Thereafter, thecard may be activated (operation 314), meaning that the card may be usedto execute a transaction, e.g., may be used to purchase a good orservice on credit (or, as discussed below, may be used in anothermanner, such as to transact a purchase as a debit card, stored valuecard, etc.). To facilitate execution of a transaction, the PIN assignedto the transaction card is communicated to the approved applicant. Forexample, the PIN may be communicated to the cardholder via a shortmessage service message, via an e-mail received by a wireless or otherdevice, via the point-of-sale device, etc. This PIN may be either apermanent PIN, or may be active for only a particular period of time,for a particular number of uses, on in connection with transactionhaving a monetary value of less than a particular amount.

If, on the other hand, operation 310 indicates that the application isdeclined, then the card is not activated (316), meaning that the cardmay not be used to execute a transaction.

Operations 300-314 may be carried out nearly instantaneously. Forexample, according to some embodiments, operations 300-314 may becarried out within less than one minute, and according to otherembodiments such operations may be carried out in less than 30, 15,and/or 5 seconds. Thus, for example, an applicant may apply for a cardwhile initiating a purchase at a point-of-sale device at a merchantstore, and may actually have the card activated, so that the applicantcan use the card to transact that purchase (and other purchases at othermerchants, as well). Because the card is anonymous, there is no need forthe card to bear printing identifying the cardholder, nor is there aneed for the storage medium of the card to have such identificationinformation or PIN encoded therein. Thus, after the application process,there exists no waiting period for the card to be printed upon or forthe storage medium thereof to be encoded with information identifyingthe applicant.

As described with reference to FIG. 2, to transact a purchase using thetransaction card described herein, a point-of-sale device (e.g., cashregister) may read a given card, and may communicate the information viaan open network to the transaction platform's server. FIG. 4 depicts anexemplary networking environment in which the point-of-sale device 202of FIG. 2 may reside. As can be seen from FIG. 4, a given merchant storemay have a plurality of point-of-sale devices 202 situated therein. Eachpoint-of-sale device 202 may be coupled to a local area network (LAN)400. The LAN of FIG. 4 is depicted as being an Ethernet network, for thesake of illustration only. The LAN 400 may be of any structure andutilize any protocol.

The various point-of-sale devices 202 communicate with a server 402 viathe LAN 400. The server 402 maintains a database 404 that storesinformation regarding all of the transactions conducted via each of thepoint-of-sale devices 202. (Typically, each transaction is identified bya transaction identifier, as discussed below). The server 402 maytransfer information to/from an open network 408, such as the Internet,via a router 406.

The network environment of FIG. 4 is exemplary, and presented for thesake of illustration only. Many other environments exist and are knownby those of ordinary skill in the art. FIG. 5 depicts a transactionkernel that is deployed, i.e., the various software units are stored andexecuted at, either the point-of-sale devices 202, the server 402, somecombination of the two, and/or any computing device in communicationwith either the point-of-sale devices and/or server 402. Herein, thekernel of FIG. 5 is discussed proceeding from the assumption that it isdeployed in the network environment of FIG. 4, but its modules areadaptable to use in any networking environment, as understood by one ofordinary skill in the art.

Turning to FIG. 5, the point-of-sale device 202 is coupled to an inputdevice 500, such as a magnetic strip or bar code reader, or RFIDtransceiver. During the transaction of a purchase, the magnetic stripreader 500 is used to read the magnetic strip on the card. Of course, ifthe storage medium of the card is a bar code, then the input device 500may be embodied as a bar code scanner. Similarly, if the storage mediumof the card is an RFID chip, then the input device 500 may be embodiedas an RFID transceiver. When the input device 500 reads the storagemedium of the card, a card number uniquely identifying the card is readtherefrom. The input device 500 may also include a keypad, which may beused by the cardholder to enter a personal identification number (PIN).The PIN code and card number are communicated from the input device 500to the point-of-sale device 202.

A point-of-sale device 202 has the structure of a general-purposecomputing device. In other words, the point-of-sale device 202 includesthe components typically found in a general-purpose computer, i.e., itincludes a processor that is coupled to one or more stages of memorythat store software and data. The processor communicates, via aninput/output (I/O) bus, with various input, output, and communicationdevices, including a display, such as a monitor, and may communicatewith a keyboard, a mouse or other pointing device, such as a touch pad,and/or speakers, to name a few such devices. Various peripheral devicesmay also communicate with the processor via the I/O bus, including anetwork interface card, a hard disc drive, or other mass data storagedevice, removable media drives, such as a CD ROM drive or a DVD drive(which may be both readable and writable), a wireless interface, amagnetic strip reader, a barcode reader, an RFID transceiver, etc. It isunderstood that computers presently employ many chip sets andarchitectures. The point-of-sale device 202 broadly represents all suchchip sets and architectures, and the various embodiments of the kerneland various software methods described herein may execute on all suchchip sets and architectures.

A PIN code and card number extractor module 502 may be resident in thememory of the point-of-sale device 202 or in any other device incommunication therewith and/or networked thereto, and is executed by theprocessor thereof. By “module,” it is meant a unit or portion ofsoftware, such as a function, object, set of functions and/or objects,and/or a set of computer instructions (e.g., machine code) executable bythe processor of the point-of-sale device 202. Of course, thefunctionality provided by a module may also be employed by thecooperative efforts of one or more application-specific integratedcircuits (ASICs), or by the cooperative efforts of one or more ASICs andmodules of software stored in a memory device and executed by aprocessor. Upon the input device 500 communicating the PIN code and cardnumber to the point-of-sale device 202, the extractor module 502 readsthe card number and the PIN code from the data set communicated from theinput device 500 to the point-of-sale device 202. As discussed below,the extractor module 502 communicates the PIN code and card numberinformation to other software modules that may, according to someembodiments, be stored and executed by the server 402.

The point-of-sale device 202 communicates with a database 404 that ismanaged by the server 402. An application interface (API) 504 isprovided to permit the point-of-sale device 202 to interact with thedatabase 404. According to some embodiments, the database 404 isorganized according to a schema including a plurality of tablesstructured to store information concerning the items that have been soldat the store. The database 404 may store other information, as well. Forexample, if the particular merchant operates many stores, the database404 may store information concerning the items that have been sold atall of the merchant's stores, or all of the merchant's stores within aregion. Further, the database 404 may store information relating tomerchandise inventory, supplier information, and other informationuseful in operating the particular business. Like the network structureof FIG. 4, the schema of the database 404 varies from merchant tomerchant and may vary from store to store, as is understood by one ofordinary skill in the art.

Although the schema employed by the database 404 may vary from merchantto merchant, it is customary for the database to include a table thatstores records describing the details of each transaction. Such a tableis described herein as a “transaction table” 506. A transaction table506 is typically organized to uniquely identify each transaction with atransaction identifier 508, i.e., the transaction identifier 508 may bethe primary key for the transaction table 506. A plurality of fields 510may be associated with each transaction identifier 508. These fields 510provide for storage of information concerning each item included in thetransaction. For example, the fields may include one or more of thefollowing: (1) a stock keeper unit (SKU) number of each item included ina transaction; (2) the price of each item included in the transaction;(3) an internal description of each item included in the transaction;(4) an external description of each item included in the transaction;(5) a general description of each item included in the transaction; (6)a category into which each item included in the transaction falls; (7)the sales tax associated with each item included in the transaction; (8)the date on which the transaction occurred; (9) the time at which thetransaction occurred; (10) an identifier indicating the particular storeat which the transaction occurred; (11) an identifier indicating theparticular point-of-sale device at which the transaction occurred; (12)an identifier indicating the employee operating the particularpoint-of-sale device at the date and time of the transaction; (13) anindication of the method of payment used to transact the particulartransaction, e.g., cash, credit card, etc.; (14) the total price of thetransaction; (15) an indicator of the type of transaction, e.g.,purchase, refund, return, data inquiry, etc.; and/or (16) any otherinformation describing the subjects and/or circumstances of thetransaction. Information generally of the variety just recited, i.e.,information going beyond the total price, date, time, and/or location(e.g., identification of merchant and city/state) of the transaction, isreferred to as “level three data.”

After a point-of-sale device 202 has scanned each item involved in atransaction, a payment technique may be selected. The point-of-saledevice 202 may present a screen inquiring as to the type of transactionto be executed via the transaction card, e.g., whether the card is to beused as a credit card, a debit card, and/or as a stored value card (asmentioned previously, the transaction card may be used as a credit cardin the context of one transaction, as a debit card in anothertransaction, and as a stored value card in the context of yet anothertransaction). The point-of-sale device 202 uses the API 504 to create anew transaction identifier 508 to uniquely reference the transaction itis executing. The transaction type and level three data concerning thetransaction may then be stored in the transaction table 506 inassociation with the transaction identifier 508. According to someembodiments, the PIN and card number extractor 502 also captures thetransaction type, and delivers the transaction type data to the secondencryption module 522, as discussed below.

A monitor module 512 interacts with the API 504 to observe the creationof a new transaction identifier 508 within the transaction table 506.Upon observation of the creation of a new transaction identifier 508,the monitor module 512 calls the data extraction module 514 to initiateits operation.

According to some embodiments, the data extraction module 514 interactswith the API 504 to extract the level three data, including thetransaction identifier, associated with the new transaction. Accordingto other embodiments, the data extraction module 514 interacts with theAPI 504 to extract less than the full extent of the level three data.For example, the data extraction module 514 may obtain only thetransaction identifier and total price of the transaction from thedatabase 404. For the sake of illustration only, the present documentdescribes the data extraction module 514 as obtaining the full extent ofthe level three data from the database 404.

To permit the data extraction module 514 to obtain data from thedatabase 404, at the time of installation of the kernel depicted in FIG.5, the data extraction module is supplied with information permittingsuch extraction. For example, the code and/or data space of the dataextraction module 514 may be altered in light of the name of thetransaction table 506, and the names of the various fields 510 thereinfrom which it is to capture data.

As the data extraction module 514 captures the level three data, it isentered into a region of memory 516 for transfer to a first encryptionmodule 520. Prior to transfer of the first encryption module 520, asufficiency module 518 examines the captured data and interacts with thePIN and card number extractor 502 to ensure that: (1) the dataextraction module has captured at least a total price and a transactionidentifier; and (2) the PIN and card number extractor 502 has capturedthe card number and PIN. If the aforementioned data has not beencaptured, an error is indicated, and operation of the kernel vis-à-visthe transaction is halted. If, on the other hand, the aforementioneddata has been captured, then the data stored in the memory 516 is passedto the first encryption unit 520.

The first encryption unit 520 encrypts the level three data and thetransaction type data (transaction type data is received from the PINand card number extractor 502, as shown in FIG. 5) using the PINcaptured by the PIN and card number extractor 502 as the encryption key,thereby creating a first encrypted object 600. The first encryptedobject 600 is depicted in FIG. 6. The first encrypted object 600 ispassed from the first encryption module 520 to the second encryptionmodule 522.

The second encryption module 522 receives the first encrypted object 600and appends the card number thereto, creating an appended data set. (Thecard number is received from the PIN and card number extractor 502, asshown in FIG. 5). Then, a merchant password is used as a key to encryptthe appended data set, thereby obtaining a second encrypted object 602.The second encrypted object 602 is depicted in FIG. 6. The secondencrypted object 602 is passed from the second encryption module 522 tothe third encryption module 524. According to some embodiments, themerchant password is a 64, 128, 256, 512-bit value, or a value ofanother length appropriate to protect the second encrypted object 602from being decrypted by an interloper, when transmitted along an opennetwork. The merchant password typically remains a secret known only toa select set of necessary employees at the merchant and at thetransaction platform. According to some embodiments, the merchantpassword is entered into the code and/or data space of the kernel at thetime of installation of the kernel on the merchant's server 402.

The third encryption module 524 receives the second encrypted object 600and appends a merchant identifier, a store identifier, and apoint-of-sale device identifier thereto, thereby creating an appendeddata set. The merchant identifier is a value uniquely identifying themerchant (e.g., a value indicating that the transaction occurred at aTarget store). The store identifier is a value that uniquely indicatesthe particular store at which the transaction is taking place (e.g., avalue indicating at which Target store the transaction is occurring).The point-of-sale device identifier is a value that uniquely identifiesthe particular point-of-sale device 202 at which the transaction isoccurring (e.g., a value indicating at which cash register thetransaction is occurring). The merchant identifier, a store identifier,and a point-of-sale device identifier are obtained from the database404, via the API 504. According to some embodiments, at the time ofinstallation of the kernel of FIG. 5 upon a merchant's server 402, thename of the table(s) and fields within the database 404 containing suchinformation is entered into the third encryption module 524 (e.g.,entered into the code and/or data space of the third encryption module524), so that it can interact with the API 504 to obtain suchinformation. The third encryption module 524 then encrypts the appendeddata set with a public key associated with the transaction platform 204,yielding the transport object 604. The transport object 604 is depictedin FIG. 6. According to some embodiments, the public key is a 64, 128,256, or 512-bit value, or a value of another length appropriate toprotect the transport object 604 from being decrypted by an interloper,when transmitted along an open network. The transport object 604 ispassed to a secure socket layer (SSL) module 526, along with an SSLencryption key for use by the SSL module 526. According to someembodiments, the aforementioned SSL encryption key is generated by arandom number generator, and the public key may be directly hardcodedinto the third encryption module 524.

The SSL module 526 receives the transport data object 604 and uses theSSL encryption key to encrypt the transport object, yielding anencrypted transport object 606. The encrypted transport object 606 isdepicted in FIG. 6. Although FIG. 5 depicts the SSL encryption key asbeing generated by a random number generator in the third encryptionmodule 524, according to other embodiments, the SSL encryption key maybe generated by the SSL module 526.

The SSL layer 526 passes the encrypted transport object to thetransmission control protocol/internet protocol (TCP/IP) module 528 forcommunication through the open network 408 to the transaction platform'sserver. (According to the exemplary network environment of FIG. 4, thetransport object is communicated as one or more packets routed throughthe router 406 to the open network 408).

An exemplary embodiment of a software system executing on thetransaction platform's server is depicted in FIG. 7. The transactionplatform's server is structured so as to include at least similarelements as a general-purpose computing device. In other words, thetransaction platform's server includes the components typically found ina general-purpose computer, i.e., it includes a processor that iscoupled to one or more stages of memory that store software and data.The processor communicates, via an input/output (I/O) bus, with variousinput, output, and communication devices, including a display, such as amonitor, and may communicate with a keyboard, a mouse or other pointingdevice, such as a touch pad, and/or speakers, to name a few suchdevices. Various peripheral devices may also communicate with theprocessor via the I/O bus, including a network interface card, a harddisc drive, or other mass data storage device, removable media drives,such as a CD ROM drive or a DVD drive (which may be both readable andwritable), a wireless interface, a magnetic strip reader, a barcodereader, an RFID transceiver, etc. It is understood that serverspresently employ many chip sets and architectures. Throughout thisdocument the transaction platform's server is referred to in thesingular, i.e., as though it is a singular machine. Of course, theserver may actually be composed of a plurality of servers that cooperateto perform the functionality described herein. For example, two or moreservers may individually perform all of the functionality describedherein, and they may handle clients (i.e., various transaction kernelsinstalled at various sites), as assigned by a load balancer. Also, twoor more servers may cooperate in the sense that a first server mayperform a subset of the operations described herein, and may communicatewith a second server that performs another subset of the operationsdescribed herein.

The description of the functionality of FIG. 7 is provided withreference to a credit transaction, for the sake of illustration only. Asdiscussed herein, below, the same infrastructure may be used to processdebit transactions, stored value transactions, data access transactions,and combinations thereof.

The software system of FIG. 7 includes a TCP/IP module 700 that receivesone or more packets, the combined payload of which make up the encryptedtransport object 606. The TCP/IP module 700 reconstitutes the encryptedtransport object 606 from the one or more packets, and passes theencrypted transport object 606 to the SSL module 702. The SSL module 702uses the SSL encryption key to decrypt the encrypted transport object,yielding the transport data object 604. (The SSL module 702 has accessto the SSL encryption key by virtue of the negotiation that initiatedthe secured SSL session, as is understood by those of ordinary skill inthe art). The transport data object 604 is then passed to the firstdecryption module 704.

The first decryption module 704 has access to a database 706 via an API708. The database 706 contains financial data for each cardholder, andother data, as well as described in greater detail, below. According tosome embodiments, the first decryption module 704 accesses the database706 to obtain the transaction platform's private key, and then decryptsthe transport object 604, yielding the second encrypted object 602 andthe appended merchant identifier, store identifier, and registeridentifier. According to other embodiments, the first decryption module704 has the aforementioned private key hardcoded into its code space, oraccesses the private key from a region of memory. In any case, thesecond encrypted object 602 and the appended merchant identifier, storeidentifier, and register identifier is passed to the second decryptionmodule 710.

The second decryption module 710 also has access to the database 706 viathe API 708. The second decryption module 710 uses the merchantidentifier that is passed to it from the first decryption module 704 toobtain the merchant password. For example, the merchant identifier maybe used as a key to access a table in the database 706 to find themerchant password. Thus, the second decryption module 710 may access atable that relates the merchant identifier to the merchant password, andmay use the merchant identifier as a key to obtain the merchantpassword. The merchant password is then used to decrypt the secondencrypted object 602, yielding the first encrypted object 600 with thecard number, merchant identifier, store identifier, and registeridentifier appended thereto. The first encrypted object 600 and theaforementioned appended data are passed to the third decryption module712.

The third decryption module 712 receives the just mentioned data,including the card number, and accesses the database 706 via the API708. The third decryption module 712 uses the card number to obtain thecard identifier and PIN from the database 706. The card number may beused as a key to access a table relating the card number to a cardidentifier and, either directly or indirectly, to the PIN. For example,the card number may be used to access a table that associates the cardnumber to a card identifier and a PIN code identifier. Then, using thePIN code identifier, a table relating the PIN code identifier to the PINmay be accessed, in order to obtain the PIN. As one of ordinary skill inthe art understands, the PIN may be stored in an encrypted format, sothat it cannot be misappropriated. Upon retrieval from the table inwhich it is stored, the PIN is decrypted, assuming that the requestingtask has a proper access level to request such decryption. Uponreceiving the PIN, the third decryption module 712 decrypts the firstencrypted object 600, yielding the level three data, together with thecard number, merchant identifier, store identifier, and registeridentifier. (Of course, as discussed with reference to FIG. 5, thepayload of the first encrypted object 600 may, in some instances, onlyinclude the total price and a transaction identifier).

The aforementioned data is passed to the balance check module 714,which, like the various decryption modules 704, 710, and 712, has accessto the database 706 via the API 708. First, the balance check module 714obtains the current balance and credit limit associated with the cardnumber from the database 706. For example, the balance check module 714may access a table containing relating card detail information to a cardidentifier. Then, using the card identifier, which was obtained by thethird decryption module 712, as a key to look up the current balance andcredit limit values are obtained. The sum of the current balance andtotal price of the proposed transaction is compared with the creditlimit. If the sum exceeds the credit limit, the proposed transaction maybe declined (discussed later, below). Otherwise, process flow is passedto the fraud check module 716.

The fraud check module 716 has access to the database 706 via the API708. The fraud check module 716 obtains fraud indicator rules associatedwith the card number from the database 706. According to someembodiments, some or all of the rules may be determined by thecardholder (this is discussed below). Also, some or all of the rules maybe system rules that are generated without input from the cardholder.The parameters of the proposed transaction and recent transactions maybe compared with the fraud indicator rules. If one of the fraudindicator rules tests positive, the cardholder may be contacted. Thecardholder may be contacted via the telephone by an employee of thetransaction platform (note that the cardholder's contact information,including the cardholder's telephone number is stored in a tableassociated with the master account and card identifier, as shown in FIG.8). The cardholder may be asked to confirm his identity (e.g., theindividual answering the telephone may be asked to identify himself, andmay be asked for the PIN associated with the card number), and is alsoasked to confirm that the transaction is legitimate. Additionally, thecardholder may be contacted via the operation of a short message service(SMS) module 718. For example, the SMS module 718 may send an SMSmessage to the cell phone of the cardholder (this number is stored inthe database 706 in association with the card number), asking thecardholder to confirm that the proposed transaction should be approved.To allow the confirmed transaction to be approved, the cardholder mustrespond in the affirmative, and must also enter his PIN code. The SMSmodule 718 receives the response message, and returns it to the fraudcheck module 716. If the return message indicates that the proposedtransaction is not to be approved, then the proposed transaction isdeclined (discussed later), and the card is frozen (also discussedlater). If the return message indicates that the transaction islegitimate, and also contains the PIN associated with the card,execution flow is passed on to profile check module 720.

The profile check module 720 operates upon child cards. A “child” cardis a card that is associated with the same master account (discussedwith reference to FIG. 8) to which a parent card is associated. Theeffect of such association is that the parent and any number ofassociated child cards draw upon the same funds, i.e., draw upon thesame line of credit, upon the same stored value, upon the same balanceof pre-paid services or goods, and/or upon the same checking account orbank account. The cardholder associated with the parent card receives astatement presenting the transactions of all accounts associated withthe master account, meaning that the cardholder of the parent cardreceives a statement presenting transactions executed via both theparent card and any child cards. The parent card may impose rules uponthe spending permissions of the child card, as discussed in more detail,below. For example, assume the circumstance in which a parent is acardholder. The parent may create a child account for use by his son ordaughter. The bill generated by the child account is rolled up into thebill on the parent's account. The parent may assign rules to the child'saccount. For example, the parent may associate a rule with the childaccount permitting the child account to incur up to a chosen level debtper a chosen unit of time (example: $250 per month). Other rulesinclude, without limitation: (1) disallowing purchases of certain SKUsor classes of SKUs (example: disallow purchases of SKUs indicating thatthe purchased item is alcohol); (2) disallow purchases occurring atcertain merchants, merchant types, and/or merchant categories; (3) allowonly purchases occurring at certain merchants, merchant types, and/ormerchant categories. To this end, according to some embodiments, thedatabase 706 stores one or more tables that associate a merchant typeand/or merchant category for the various merchant identifiers storedtherein. The profile check module 720 operates by retrieving the rules(if any) associated with a card number, and testing the proposedtransaction against rules. If any of the rules are violated, thecardholder of the parent card may be contacted, as described withreference to the fraud check module 716, to allow the transaction.

For example, the profile check module 720 may operate by accessing atable that associates card identifier of child card(s) with the parentcard that controls it. The profile check module 720 may examine thetable to determine whether the card identifier (retrieved initially bythe third decryption unit 712) is presented therein as corresponding toa parent card. If it is not found therein, the card is not a child card,and no rules imposed by a parent card are associated therewith.Alternatively, if it is found therein, it is a child card, and may haverules associated with it. In such a circumstance, the aforementionedtable may associate the child card with a value that may be used as akey to yet another table that associates the aforementioned value with apointer that points to executable code implementing the rules chosen forthe card. The executable code is then executed to determine if any ofthe rules are violated, as described above.

If either the balance check module 714, the fraud check module 716, orthe profile check module 720 indicates that the transaction should notbe allowed, then control passes to the decline/freeze module 722. Thedecline/freeze module 722 declines the transaction, and sends a messageto the point-of-sale device indicating that the proposed transaction hasbeen declined (details regarding the structure of such a return messageto the point-of-sale device are presented below). Additionally, if thefraud check module 716 indicates that the purchase is fraudulent, thenthe account associated with the card is frozen, meaning that no futuretransactions will be permitted, until the card is re-activated.

If each of the balance check module 714, the fraud check module 716, andthe profile check module indicates that the transaction should beallowed, then control passes to the record transaction module 724. Therecord transaction module enters the data recovered by the threedecryption modules 704, 710, and 712, including the level three data,into the database 706. For example, a transaction identifier—differentfrom the one assigned by the merchant—is assigned to the transaction. Anew record, identified by the newly assigned transaction identifier iscreated in a table that relates details relating to a transaction withthe newly assigned transaction identifier. Thereafter, the variousfields of the new record are populated using the data recovered by thethree decryption modules 704, 710, and 712, including the level threedata. (The merchant's transaction identifier is also stored in theaforementioned table in association with the newly-assigned transactionidentifier, thereby preserving the association between the transactionplatform's transaction identifier and the merchant's transactionidentifier).

As mentioned previously, the point-of-sale device located at themerchant is notified of the decline/approval of the transaction.According to some embodiments, a message structured as shown in FIG. 9is transmitted via the SSL module 702 and TCP/IP module 700 to thepreviously discussed kernel executing on the merchant's server 402. Ascan be seen from FIG. 9, the message includes an indication of whetherthe proposed transaction was approved or declined 900, the transactionidentifier 902 assigned by the merchant's database, and the merchantidentifier, store identifier, and register identifier 904.

The message of FIG. 9 is received by the TCP/IP module 528 of the kernel(FIG. 5), and is passed to the SSL module 526, whereupon it isdecrypted. The payload thereof is transferred to the acknowledge module530, which uses the API 504 to update the database 404 with theinformation concerning the approval or decline. (The indication 900 ofwhether the proposed transaction was approved or declined is associatedwith the merchant's transaction identifier 902, which is included withinthe message of FIG. 9). According to some embodiments, at the time thekernel is installed upon the merchant's server 402, the acknowledgemodule 530 is altered to include the appropriate table and field namefor entry of such information (e.g., the code and/or data space of theacknowledge module 530 is altered to include the table name and fieldname of the appropriate location for entry of such information).Thereafter, the merchant identifier, store identifier, and registeridentifier 904 are used to determine how to route the informationconcerning the decline/approval to the appropriate point-of-sale device202, and the transaction identifier is used to decline/approve theappropriate transaction.

As described in the foregoing discussion, according to some embodiments,the level three data that is the subject of a given transaction iscollected, communicated to the software system of FIG. 7, and stored inthe database 706, at a point in time that is contemporaneous with theexecution of the transaction. This provides certain advantages that,while notable, are not essential to practice of the invention. Forexample, because the level three data is captured and entered into thedatabase 706 during execution of the transaction (as opposed to afterexecution of the transaction), the software system may examine the levelthree data and compare such level three data against various rules, todetermine if a proposed transaction should be approved or denied. Asdiscussed below, a cardholder may select fraud detection rules that, forexample, identify a proposed transaction as being potentially fraudulentif a particular good or class or categories of goods are the subject ofthe transaction. Clearly, such rules cannot be imposed if dataconcerning the identity of the goods that are the subject of thetransaction is either absent or not gathered until after the transactionhas been executed. As also discussed below, a cardholder may customizerules governing permissible spending from a “child card.” For example acardholder may specify that a child card is forbidden to execute atransaction in which a particular good or class of goods is a subjectthereof. Again, such rules cannot be imposed if data concerning theidentity of the goods that are the subject of a given transaction iseither absent or not gathered until after the transaction has beenexecuted. Finally, because the level three data is gathered and storedcontemporaneously with the transaction, a cardholder may be presentedwith information concerning the identity of items purchased with anycard associated with his or her card (including, for example, itemspurchased via a child card) and the identity of which card numberconducted such transactions. Such information may be provided in realtime or in near real time, such as via a web site or a call center.

According to some embodiments, the database 706 may be organized asshown in FIG. 8. As can be seen from FIG. 8, the database may beorganized so as to associate a card number 800, i.e., a set of data thatis encoded/stored/contained on a storage medium of a transaction cardand that uniquely identifies that card, with a card identifier 802. Acard identifier 802 is a set of data (e.g., an integer) that is uniquelyassociated with a card number 800 in the database 706. The cardidentifier, in turn, is associated with a master account number 804.

The master account number 804 is a set of data that is uniquelyassociated with all of the account information 806 of every account thatmay be accessed via the transaction card, and is also associated withall of the cardholder information 808 that may be accessed via the card.For example, the master account number is associated with the balance ofevery account that may be accessed via the card. Thus, it may beassociated with a credit balance (as when the card is used as a creditcard), a bank account balance (as when the card is used as a debitcard), and/or a stored value balance (as when the card is used as astore value card, e.g., gift card, prepaid good and/or services card,etc.). The master account number 804 is also associated with all of thedetails, e.g., level three data, of all of the transactions executedthrough every account that may be accessed through the card. Further,the master account number 804 is associated with every rule governingthe card, e.g., interest rules, late payment rules, fraud detectionrules, child account spending rules, etc. Still further the masteraccount number 804 is associated with information relating to thefinancial institution tied to each account that may be accessed throughthe card, e.g., the bank that extends the line of credit behind thecard's use as a credit card, etc. In general, every unit of datarequired and/or associated with the card's capacity as a credit card,debit card, and/or stored value card is associated with the masteraccount number, either directly or indirectly.

The aforementioned arrangement presents certain advantages that arenoteworthy, but not essential to practice of the invention. For example,assuming that the transaction card associated with the card number 800were to be stolen, another card, having another card number, such ascard number 810 may be reassociated with the master account number (byway of a new card identifier 812). In so doing, all of the accountinformation 806 and cardholder information 808 remains in place, and nosuch information is lost.

Another advantage inheres in the arrangement of FIG. 8, which isnoteworthy but not essential to the practice of the invention. As shownin FIG. 8, more than one card number 800 and 810 may be associated withthe same master account number 804. Consequently, a cardholder may electto possess two transaction cards-one for personal use, and one forbusiness use, for example. (Although this example describes two cardnumbers 800 and 810 associated with a particular master account number804, any number of card numbers 800 and 810 may be associated with thesame master account number 804). Thus, a single statement or webpage maypresent an account breakdown 814 to the cardholder, showing, forexample, total spending for each card, or even presenting, on atransaction-by-transaction basis all of the level three data (e.g., eachitem and cost associated therewith) for each card.

According to some embodiments, a transaction may be conducted withoutthe use of a transaction card, and is conducted, rather, via wirelessdevice, such as a cellular telephone and/or a personal digitalassistant. For the sake of illustration only, the following exemplaryembodiment is described with reference to a cellular telephone. Asdescribed previously, the transaction may be initiated at apoint-of-sale device 202, where the bar codes associated with the itemsto be purchased are scanned by an attendant. At this point, theattendant asks the cardholder for his cellular telephone number (orotherwise acquires the cellular telephone number, e.g., has thecardholder call a specific number that captures the cardholder'scellular telephone number and communicates it to the point-of-saledevice 202, the merchant server 402, or to a computer system incommunication with either the point-of-sale device 202 and/or themerchant's server 402), and the telephone number is entered into thepoint-of-sale device 202.

The point-of-sale device 202 then enters the level three data intodatabase 404, as described previously with reference to FIG. 5. Again,this causes the monitor module 512 to observe the creation of a newtransaction identifier 508 in the transaction table 506, therebypropagating the set of events described previously, with the followingexceptions. The first encryption module 520 is instructed to use thetelephone number of the cardholder's cellular telephone to encrypt thelevel three data, yielding a first encrypted object 1000, as shown inFIG. 10. Then, the second encryption module 522 appends the cellulartelephone number to the first encrypted object (in lieu of placing thecard number there), and encrypts the appended data set with the merchantpassword, as described previously, yielding the second encrypted dataset 1002. The remainder of the kernel functions as described previously.

At the transaction platform's server, much of the handling is similar tothat described previously with reference to FIG. 7, with the followingexceptions. When passed the first encrypted object and appended data,the third decryption unit 712 detects that a cellular telephone numberhad been inserted in place of the card number (for example, such adetection may be made virtue of the fact that a cellular telephonenumber and a transaction card number are different lengths). Upondetecting that a cellular telephone number has been inserted in place ofthe card number, the third decryption unit 712 uses the cellulartelephone number as the decryption key to decrypt the first decryptedobject. Thereafter, the third decryption unit 712 invokes the SMS module728 with the cellular telephone number. The SMS module 728 sends an SMSmessage to the telephone number provided thereto. The SMS messageindicates the total price of the transaction and the name of themerchant store at which the proposed transaction is to be conducted. Themessage prompts the user to either confirm or deny the transaction. Ifthe user confirms the transaction, he enters his PIN into the telephone,and an applet and/or other form of executable code bundles the PIN withthe user's card number (the applet and/or other form of executable codeis previously altered to include the card number in its code or dataspace), generating a response that indicates that the proposedtransaction is to be confirmed, and including therewith the user's cardnumber and the PIN associated therewith. According to some embodiments,the reply message confirming or denying the transaction is communicatedvia a wireless Internet connection established by the device and isencrypted via the SSL protocol. The reply message is returned to thethird decryption unit 712. If the reply message denies the transaction,then the transaction is declined, as described previously with referenceto FIG. 7. On the other hand, if the reply message approves thetransaction, then the third decryption module 712 accesses the database706 to retrieve the user's PIN, based upon the card number, as describedpreviously. If the retrieved PIN matches the PIN entered into thecellular telephone and passed to the third decryption module 712 via theSMS module 728, then the process continues as described previously withreference to FIG. 7 (i.e., the balance check, fraud check, and profilecheck are performed, as usual).

The effect of the foregoing is that a cardholder may transact a purchaseby simply providing his cellular telephone number to an attendant at apoint-of-sale device 202. After the item(s) to be purchased have beenscanned in by the attendant, the cardholder receives an SMS, asking thecardholder to confirm the correctness of the total price. The cardholderconfirms by responding to the SMS in the affirmative and entering in hisPIN.

According to some embodiments, a cardholder may utilize a wirelessdevice, such as a cellular telephone, to transact a purchase of a goodor service from a vendor that does not have a wired point-of-salearranged to interact with the kernel of FIG. 5. The wireless isprogrammed with an applet to permit entry of a total monetary sum of thetransaction, a merchant identifier, and the PIN number associated withthe cardholder's transaction card. According to some embodiments, theapplet is configured at installation to have access to the cardholder'scard number. The applet then combines the card number, merchantidentifier, total amount of the transaction, and a transaction type dataunit describing the type of transaction into a packet that is firstencrypted using the PIN as an encryption key, and then is encryptedusing SSL. At the software system of FIG. 7, the packet is decrypted,first by the SSL module 702, and then by the third decryption module712. Thereafter, the process proceeds as previously described.

As mentioned previously, the kernel of FIG. 5 and software system ofFIG. 7 may cooperate to execute various sorts of transactions, and mayaccomplish such variety of transactions by varying the data carried inthe encrypted transport object of FIG. 6. For example, theaforementioned infrastructure may cooperate to perform a “private clubpurchase.” A private club purchase is a purchase conducted at a merchantthat requires a membership (e.g., Sam's Club, a movie rental store,etc.). For example, consider the scenario in which an individual wishesto rent a movie from a movie rental store. Such a store typicallyrequires presentation of a membership card, in order to conduct apurchase. The membership card typically bears a storage medium (barcode, magnetic strip, etc.) encoding a number associated with amembership account. Such a membership card is obsolete in view of theinfrastructure herein.

As an initial step, a cardholder may associate his membership accountnumber (or other identifying number associated therewith, such as thenumber encoded on the storage medium of his membership card) with hismaster account. When, renting his movie, the cardholder presents atransaction card of the sort disclosed herein to both purchase the movierental, and to present his membership account. The employee may “swipe”the card as described previously, setting in motion the eventspreviously described. However, in this context, the transaction typedata is set to a value to indicate that a private club purchase is beingcarried out. (The level three data carries data describing the title ofthe movie being rented, etc.). Thus, an encrypted transport objecthaving a merchant identifier identifying the movie rental merchant, astore identifier identifying the particular store, a point-of-saleidentifier identifying the particular point-of-sale device, the cardnumber of the transaction card, the level three data as just described,and the transaction type data as just described is communicated to thesoftware system of FIG. 7.

Upon receiving the encrypted transport object carrying the systembehaves as previously described, with the following exception: thesystem accesses a table in the database 706 that relates the privateclub's membership number (or other number associated therewith) with themaster account and card identifier. The system acquires theaforementioned membership number and returns that number in the responsepacket of FIG. 9, in addition to the elements shown therein. Hence, thepoint-of-sale device is provided with approve/decline informationregarding the financial transaction, and is also provided with themembership number of the cardholder. Thus, the need to complete aprivate club transaction with two cards is eliminated.

The aforementioned infrastructure may also be used to conduct a dataacquisition transaction. A data acquisition transaction is a transactionin which the card is used to obtain information associated with thecard's identifier and with the master account. Such retrievedinformation could be simple. For example, the retrieved informationcould present an indication of whether an individual is indeed a memberof an organization (e.g., whether an individual is a member of a healthclub). Alternatively, the information could be complex, such asindicating health information of the cardholder. In the context of adata acquisition transaction, the infrastructure behaves as previouslydescribed, with the following exceptions, which are described withreference to a cardholder using his card to provide healthcare to ahealthcare institution (hospital, clinic, etc.).

As an initial matter, the cardholder establishes a set of rules withinthe database 706 that identify which sort of data can be retrieved. Forexample, the rules describe the sort of health care data that can beretrieved from the card by various institutions identified by theirrespective merchant identifiers.

At the health care facility, the card is “swiped” to read the storagemedium thereon, and the series of events previously described occur.However, in this context, the cardholder may not be conscious, so thePIN to be entered may be “911,” or some other pre-defined PIN. Thetransaction type data is set to a value to indicate that a dataacquisition transaction is being carried out. (The level three data maybe null or may be filled with dummy data, as may be the store identifierand the point-of-sale identifier, however, in some instances thesefields are populated so that a response message can be routed to theproper transaction execution device within the health care facility).Thus, an encrypted transport object having a merchant identifieridentifying the health care facility, the card number, and thetransaction type data as just described is communicated to the softwaresystem of FIG. 7. (Again, in certain instances, the store identifier andpoint-of-sale identifier may be populated).

Upon receiving the encrypted transport object, the system behaves aspreviously described, with the following exceptions. Upon identifyingthat the merchant identifier corresponds to a health care facility andthat the transaction type data corresponds to a data acquisitiontransaction, the third decryption module is bypassed, as the level threedata is null. Then, the software system accesses the database 706 toobtain the rules governing access to the data associated with themerchant identifier. For example, the database 706 may contain a tablerelating each merchant identifier, master account, and card identifierwith the cardholder data that may be returned thereto in response to adata acquisition transaction. The software system then implements therules, returning the data permitted to be returned to the healthcarefacility, given the rules. Thus, the transaction card described hereinmay be used to provide any variety of information to any variety oforganization.

To permit the foregoing transactions, the front end module of FIG. 7 mayprovide a web site into which a cardholder may login. The web site maypresent one or more web pages structured to permit the cardholder toassociate any data with his card, including health care data, insurancedata, club membership data, or any other data, including user-specifieddata. The web site may also present one or more web pages structure topermit the cardholder to associated rules governing access to such data,for example, on a merchant-by-merchant (entity-by-entity) basis.

Some features of the system described with respect to FIGS. 2-10 are ofnote, but not essential to practice of the invention. As can be seenfrom FIG. 2, for example, the transaction system does not include anyinterchange actors and therefore eliminates system components andfinancial charges related thereto. For example, as compared to thesystem of FIG. 1, it can be seen that the system of FIG. 2 requires noprivate network lines or elements. Thus, the interchange actorsresponsible for the creation and maintenance of such network lines andelements are eliminated from the process of execution of a transaction.Therefore, the costs ordinarily borne by merchants for the provision oftheir interchange services are eliminated. However, according to someembodiments, a minimal number of network line and/or elements may beutilized.

The database maintained by the transaction platform includes tableshaving fields for the inclusion of credit limits, fraud rules, and otherrules ordinarily imposed on a bank-by-bank or association-by-associationbasis. The software system of FIG. 7 includes a front end 726 thatpermits access to the database by cardholders and card-issuing banks. Acard-issuing bank may establish rules, e.g., credit limit rules, frauddetection rules, etc. associated with a given card number via the frontend module 726. The rules established by the card-issuing bank arehoused in the database 706, in association with the card number to whichthe rules apply. Therefore, the transaction platform's server does notneed to communicate with the card-issuing bank's information systemswith each proposed transaction in order to deny or approve thetransaction. Instead, the transaction platform's server may periodicallyupdate the card-issuing bank's information system (e.g., on a dailybasis), after having independently approved one or more transactionsduring the period.

Also of note, but not essential to practice of the invention, is thatthe database 706 may contain a table that relates the card identifier toa bank identifier. The bank identifier indicates the identity of thefinancial institution corresponding to a given card. By simply changingthe bank identifier in the aforementioned table, the bank associatedwith a given card is altered. Thus, a cardholder may effectivelytransfer his balance from one bank to another, without having to changecredit cards (the transaction platform simply changes the bankidentifier).

Similarly, the database 706 may include a table that associates a cardtype identifier with a card identifier. The card type identifieridentifies the sort of financial transaction(s) that is/are supported bythe card. In other words, the card type identifier indicates whether thecard is a credit card, debit card, stored value card, health caremanagement card, other form of card, or a combination of some or all ofthe foregoing. Thus, a single transaction card may be used as a creditcard in one context and a debit card in another context, for example.Stated another way, the database schema presents a mechanism by which acard number stored on a storage medium of a card and entered in thedatabase 706 relates to a card identifier; the card identifier relates,in turn, to a card type identifier that identifies the kind oftransaction to be supported by the card or information to be accessedthrough the card; the card type identifier and card identifier cooperateto relate to a set of tables organized and populated to permit the cardto act as a credit card, debit card, stored value card, healthinformation card, etc.

For example, as noted previously, the database includes a set of tablescontaining information sufficient to permit the card to act as a creditcard. These tables include, amongst other information, informationconcerning the credit limit of the card, the interest rules related tothe card, the late fee rules related to the card, the identity of thecard-issuing bank related to the card, address information permittingcontact with the information systems of the card-issuing bank (e.g., IPaddress, port information, physical address, etc.), and information ofthe like. The data in these tables can be associated with a given cardby use of a card identifier, i.e., the card identifier may be used as akey in these tables.

A second set of tables permit the card to act as a debit card. Thesetables include, amongst other information, information concerning thechecking account number and routing number of the account associatedwith the card, the balance of the checking account, and information ofthe like. Again, the data in these tables can be associated with a givencard by use of a card identifier, i.e., the card identifier may be usedas a key in these tables.

A third set of tables permit the card to act as a stored value card. Astored value card is a card that provides access to a pre-paid good orservice (e.g., a pre-paid telephone calling card, a gift card, etc.).These tables include, amongst other information, information concerningthe balance available, the merchant store(s) at which the balance may bespent, rules regarding any restrictions upon spending of the balance,and other information of the like. Again, the data in these tables canbe associated with a given card by use of a card identifier, i.e., thecard identifier may be used as a key in these tables.

Yet another set of tables permit the card to act as a health recordaccess card. A health record access card is a card that permits accessto health information stored in a database, such as the database 706 ofFIG. 7. These tables include, amongst other information, informationconcerning health insurance held by the cardholder, dental insuranceheld by the cardholder, vital statistics of the cardholder, medicationstaken by the cardholder, allergies of the cardholder, surgicalprocedures undergone by the cardholder, information concerning thephysician and other health care providers of the cardholder, personalhealth record, electronic medical record, payment adjudication,copayment calculation and settlement, and other information of the like.Again, the data in these tables can be associated with a given card byuse of a card identifier, i.e., the card identifier may be used as a keyin these tables.

As discussed with respect to FIG. 3, a scheme for rapid placement of anactivated transaction card in the possession of an applicant waspreviously described. FIG. 11 presents a method by which currentcardholders may distribute transaction cards on behalf of thetransaction platform, and may receive an incentive for so doing. Acardholder wishing to act as a distributor of transaction cards mayrequest a supply of anonymous, unassigned transactions. In response, thetransaction platform provides the cardholder with such a supply ofunassigned, anonymous cards (operation 1100). The cardholder distributesone of the anonymous cards to a person that he has reason to believewould like to be a cardholder (e.g., a friend, coworker, etc.), as shownin operation 1102. Either prior to such distribution or thereafter, thedistributed card is associated with the cardholder in the database 706(operation 1104). For example, a table may be populated to associate thecard numbers of each of the distributed anonymous cards and the cardidentifier corresponding to the cardholder to whom the cards weredelivered. The table may also be populated to include informationidentifying the person to whom the cardholder distributed the unassignedtransaction card (i.e., the prospective applicant). Operation 1104 maybe conducted, for example, by the cardholder, at a web site presented bythe front-end module 726.

After operation 1104, the procedure for application proceeds asdescribed with reference to FIG. 3. However, as shown in operation 1106,in the event that the person to whom the cardholder supplied ananonymous card is approved, incentive points are added to thedistributing cardholder's account, assuming that the applicant'sidentification information matches the identification informationsupplied by the cardholder in operation 1104 (this prevents a cardholderfrom requesting a large number of unassigned transaction cards andleaving a stack of them, for example, in a shopping center in hopes ofbeing credited for any applications resulting therefrom). Also, inaddition to, or as an alternative to incentive points, the cardholder'saccount may be credited with a monetary sum. The association operationperformed in operation 1102 permits the transaction platform's server toidentify the proper card to which to add incentive points. Upon approvalof an applicant's card, the transaction platform's software system mayexamine a table that relates the unassigned card numbers to the cardidentifiers of cardholders that received and distributed the cards, inorder to determine if the card number of the just-approved card isassociated with the card identifier of such a cardholder. If itassociated, then the corresponding card identifier is obtained. Next, atable associating the card identifier with a master account may beaccessed to obtain the master account of the cardholder that distributedthe card. Thereafter, a table relating an incentive point balance to themaster account number is accessed, and the incentive point balance isupdated to reflect the added incentive points.

According to some embodiments, the distributing cardholder's account issupplied with points, even should the person to whom the cardholdersupplied the card be rejected (operation 1108). According to someembodiments, the incentive points are spendable on items designated forsuch usage by merchants, or as may be used in the context of a genericrewards program. If a monetary sum is awarded to the cardholder'saccount, then the monetary sum may be spent on any good or service.

As discussed with reference to FIG. 6, some embodiments of thetransaction system allow for communication of level three datadescribing a given transaction. For example, assuming that a cardholdertransacted a purchase of soap, soda, and paper towels for a total of$15, the information communicated from the kernel of FIG. 5 to thesoftware system of FIG. 7 includes information identifying thetransaction as including soap at a cost of $8, soda at a cost of $4, andpaper towels at a cost of $3, for a total of $15. The software system ofFIG. 7 receives the information and, as described previously, creates atransaction identifier, identifying the $15 transaction. Each purchaseditem (and cost associated therewith) is associated with the transactionidentifier. Thus, according to such embodiments, the database 706contains data associating a particular merchant, merchant store,register, each purchased item, the cost of each purchased item, and thetotal cost of the transaction. The preservation of such level three datapermits certain heretofore impossible functionality.

One example of functionality allowed by the preservation of level threedata relates to enhanced resolutions of disputes. Presently, if a holderof a credit card reviews his or her statement and believes a particularcharge is too great, the cardholder may dispute the charge. Continuingwith the preceding example, assuming that the statement received by thecardholder presented that transaction as totaling $25, instead of $15,the cardholder would contact his credit card company, and state that thetransaction should total $15, not $25. Consequently, the entire $25transaction would be identified as being disputed, despite the fact thatonly $10 of the $25 is at issue, i.e., the cardholder acknowledges thathe owes $15, but does not believe that he owes $25. The entiretransaction must be disputed, in some instances, because a traditionalcredit card company does not receive detailed information concerning thecontents of a transaction, and in other instances because the softwaresystems employed by traditional credit card companies does not allow fordispute of a cost associated with a particular item. In response to thedispute, the card-issuing bank removes the $25 transaction from thecardholder's balance (until the dispute is resolved), and does nottransfer any funds to the merchant's bank for the transaction—not eventhe $15 that the cardholder acknowledges that he indeed owes. Thus, themerchant fails to receive the $15 that both parties acknowledge themerchant is owed, until the $10 disputed amount is resolved.

According to the method of FIG. 12, disputes may be recorded on anitem-by-item basis, as opposed to merely on a transaction-by-transactionbasis. As shown in FIG. 12, information concerning the disputed item maybe obtained from the cardholder (operation 1200). For example, acardholder may call an employee of the transaction platform and describethe item disputed. For instance, the cardholder may describe the date,merchant, and disputed item. In general, the cardholder may recite anyamount of the level three data to uniquely identify the disputed item.The employee accesses the database using the provided level information,until the specific transaction and disputed item thereof is identified.(The process of identifying the particular cost associated with aparticular item that is the subject of a transaction may be performedvia a web site presented by the front end module 726. For example, afterlogging in, a cardholder may select an option to dispute an item withina transaction. The web site may then present a series of fields,allowing the cardholder to identify the particular item to be disputed.For example, the web site may present a first field permitting thecardholder to view all transactions within a particular period of time,e.g., occurring on a given day. In response, the user may be presented aset of transaction summaries, e.g., a list of transactions identified bydate, merchant, and total amount. Selection of a particular summarycauses a list of each item that is a subject of the transaction, andcost associated therewith, to be presented. To dispute a particularcost, the cardholder may select the item to dispute, and may enter anexplanation of the dispute in a field associated therewith.) Returningto the example whereby the dispute is entered via a telephoneconversation with an employee, the transaction identifier of thetransaction of which the disputed item is a constituent is found(operation 1202). Next, a record is created within one or more tables,in order to dispute the cost associated with an identified item of theidentified transaction (operation 1204). For example, the record maydispute the cost associated with an item because the statement reflectsa purchase price of an item at a cost different than the cardholderbelieves to be the true cost. Also, the record may dispute the costassociated with an item, because the cardholder denies having purchasedthe item at all. The record describing the dispute may include datafields for description of the disputed item, and the cardholder'sreasons for disputing the cost associated with a given item. The costassociated with the disputed item is removed from the balance associatedwith the card (operation 1206), until such time as the dispute isresolved. Upon resolution of the dispute (beyond the scope of thisdisclosure, but understood by those of ordinary skill in the art), anappropriate monetary sum may be added back to the balance associatedwith the card. Finally, as shown in operation 1208, a reference to therecord created in operation 1204 may be entered into a table of disputesto be resolved.

Another function that results from the collection of level three data isthe resolution of billing statements that may be achieved. According tosome embodiments, some or all of the level three data may be included onbilling statements. According to some embodiments, a cardholder mayselect the amount of level three data presented on the statementassociated with his card. For example, the front end 726 (FIG. 7) maypresent a web site that permits a cardholder to select the level ofdetail to be presented on his statement. The web site may allow, forexample, the cardholder to indicate that all available level three databe presented. In this case, the statement presents all level three datacollected for each transaction presented in the statement. The web sitemay also allow the user to select only certain types of level three datato be presented, e.g., only description of goods/services, orclassification of goods/services, or SKU's of goods/services, etc. Thus,a statement may present, for each transaction, a description of each ofthe goods/services constituting each transaction, a classification ofeach good/service constituting each transaction, the SKU of eachgood/service constituting each transaction, etc. Of course, the web sitemay also permit the user to elect to have no level three data presentedon his statement, in which case the statement presents typicaltransaction information (merchant, date, total amount of transaction).

FIG. 13 depicts a method for establishing one or more rules governing achild card. As mentioned previously, a child card corresponds to anaccount that is a sub-account of a parent card. A cardholder of a parentcard may establish one or more rules for a child card, for example, bylogging on to a web site presented by the front end module 726 of thesoftware system of FIG. 7 (operation 1300). For example, according tosome embodiments, the web site presents a field for entry of the cardnumber of the cardholder logging into the web site. The web site alsopresents a field for entry of a password and/or PIN corresponding to thecard number. The cardholder enters his card number, password and/or PINto log in. The software system of FIG. 7 thereby identifies theparticular user of the web site as corresponding to a particular cardnumber. Alternatively, the web site may present a field for entry of auser name associated with the cardholder (and therefore associated withhis card number, etc.) and another field for entry of a password. Thelogin procedure is executed upon entry of data in these fields.

Upon logging in, the cardholder is presented with a menu of optionspertaining to his account. For example, the cardholder may be presentedwith a menu permitting the cardholder to review a real-time presentationof his statement, including his balance, review recent transactionsrelated to any account that is, in turn, related to his card number,review and/or enter information, such as medical information, insuranceinformation, etc. related to his card number, set personalized fraudrules to govern his card number, set rules to automatically alter hisPIN from time to time, and/or to set rules governing a child accountcorresponding to his parent account. As shown in operation 1302, thecardholder selects an option to set rules governing a child account. Inresponse to such a selection, as shown in operation 1304, the web sitepresents a list of child card numbers corresponding to the parent cardnumber entered in operation 1300. For example, the software system ofFIG. 7 examines a particular table in the database 706 that associates,either directly or indirectly, child card numbers with parent cardnumbers. All of the child card number associated with the parent cardnumber entered during operation 1300 are identified and presented.According to some embodiments, the name of the cardholder associatedwith the child card is presented, as well. The parent cardholder thenselects a card number from the list (operation 1306).

Thereafter, the web site present fields for customization of rules thatmay be applied to the child card. For example, the web site may presentfields allowing the parent to associate a rule with the child accountpermitting the child account to incur up to a chosen level debt per achosen unit of time (example: $250 per month). Other rules include,without limitation: (1) disallowing purchases of certain SKUs or classesor categories of SKUs (example: disallow purchases of SKUs indicatingthat the purchased item is alcohol); (2) disallow purchases occurring atcertain merchants, types of merchants, and/or categories of merchant;and/or (3) allow only purchases occurring at certain merchants. Thecardholder selects the rule for application to the child card, andenters the pertinent rule data (e.g., if the cardholder wishes to limitthe child card to a limit of $250 per month, then “250” is entered in aspending limit field, and “month” is entered in a unit of time field,e.g., may be selected from a frequency pull-down menu) (operation 1310).Finally, as shown in operation 1312, the rules selected during operation1310 are associated with the child card.

As mentioned with reference to FIG. 13, a cardholder may select fraudtriggers to be assigned to his card and/or to a child card. As was thecase with establishment of rules for a child card, fraud triggers may beestablished, for example, by logging on to a web site presented by thefront end module 726 of the software system of FIG. 7 (operation 1400,FIG. 14). As just described, according to some embodiments, the web sitepresents a field for entry of the card number of the cardholder logginginto the web site. The web site also presents a field for entry of auser name, password and/or PIN corresponding to the card number. Thecardholder enters his card number, password and/or PIN to log in. Thesoftware system of FIG. 7 thereby identifies the particular user of theweb site as corresponding to a particular card number.

As discussed with reference to FIG. 13, after logging in, the userselects an option to permit customization of fraud triggers. Thereafter,the web site responds by presenting the cardholder with variouscategorizations of fraud triggers that may be applied to the card(operation 1402). For example, as shown in box 1404, the web site maypresent the cardholder with a set of fields that that permit entry ofdata for designation of: (1) a maximum number of dollars that may bespent per unit of time, with any expenditure over the limit beingassumed to be fraudulent, e.g., any expenditure over $5000 in a day isassumed to be fraudulent; (2) a maximum purchase price for a singletransaction, with any expenditure over the maximum purchase price beingassumed to be fraudulent, e.g., any expenditure over $5000 is assumed tobe fraudulent; (3) particular classes of products that are assumed to befraudulent, e.g., a transaction including level three data having an SKUindicating that jewelry is attempting to be purchased is assumed to befraudulent; (4) an increase in expenditures exceeding a given percent,e.g., the software system of FIG. 7 may track a given cardholder'sexpenditures over the last N days (N=30, 60, 90, etc.), and maycalculate the median or average amount spent per day, with expendituresin a day exceeding the average and/or median expenditure by more than aselected percent being assumed to be fraudulent; (5) a class ofmerchants may be designated, e.g., any purchase at a jewelry store isassumed to be fraudulent; (6) particular merchants may be designated,e.g., any transaction having a merchant identifier corresponding to aselected merchant is assumed to be fraudulent; (7) particular goods orservices may be designated, e.g., any transaction including level threedata having an SKU corresponding to a selected good and/or service isassumed to be fraudulent; (8) geographic regions may be designated,e.g., any transaction having level three data indicating that themerchant store is located in a given region (state, country, continent,etc.) is assumed to be fraudulent.

The cardholder may enter data into any of the fields corresponding tothe fraud rules he wishes to be applied to the card (operation 1406).Example: to establish that an expenditure exceeding $5000 should beconsidered fraudulent, the cardholder may enter “5000” into a fieldlabeled “maximum allowable expenditure (in dollars).” Finally, as shownin operation 1408, the software system of FIG. 7 associates the selectedrules with the card number entered during operation 1400.

As also mentioned with reference to FIG. 13, a cardholder may select ascheme by which a PIN associated with his card is modified. As describedwith reference to FIGS. 13 and 14, the cardholder may commence theselection of the PIN modification scheme by logging into the web site(operation 1500). The software system of FIG. 7 thereby identifies theparticular user of the web site as corresponding to a particular cardnumber.

As discussed with reference to FIGS. 13 and 14, after logging in, theuser selects an option to permit automatic modification of the PINassociated with his card. Thereafter, the web site responds bypresenting the cardholder with various modification schemes that may beapplied to the card (operation 1502). For example, as shown in box 1504,the web site may present the cardholder with a set of fields that permitentry of data for designation of: (1) a selected quantity by which toincrement the PIN per a selected unit of time, e.g., increment the PINby a quantity of 5 each week; (2) a selected quantity by which todecrement the PIN per a selected unit of time, e.g., decrement the PINby a quantity of 5 each week; (3) a selected set of PINs, each of whichis active for a selected period of time, e.g., a selected set of 5 PINs,with the first PIN in the set being active for a week, the second PIN inthe set being active for the next week, and so on; (4) the option toperform a rotate right operation on a PIN each unit of time, e.g., afterone week PIN 4305 becomes 5430, after the next week it becomes 0543, andso on; (5) the option to perform a rotate left operation on a PIN eachunit of time, e.g., after one week PIN 4305 becomes 3054, after the nextweek it becomes 0543, and so on; (6) a selection of a period of time forwhich a PIN is active, after the expiration of such time, a new PIN israndomly selected, e.g., randomly select a new PIN each week (thecardholder may log into the web site to learn of the new PIN, or maycall a telephone number and learn of the new PIN number via interactivevoice recognition, and/or have the PIN mailed to him, for example); (7)a selected quantity by which the PIN is multiplied with the passage of aselected period of time, e.g., multiply the PIN by 2 each day; (8) aselected quantity by which the PIN is divided with the passage of aselected period of time, e.g., divide the PIN by 2 each day; and/or (9)select a static portion of a PIN that is to be appended or prepended toa dynamic portion of a PIN that changes according to any algorithm,including the aforementioned algorithms, e.g., a static portion, 12345,to which a dynamic portion, 99, is appended yielding a PIN of 1234599,which may change to be 12345100, if the dynamic portion is selected tobe altered by incrementing by one. Where a mathematical operation isperformed upon the PIN, e.g., multiplying the PIN by a selectedquantity, N, it is understood that the resulting quantity may betruncated, or otherwise operated upon, to arrive at a number of theappropriate number of digits. It should be noted, however, that,according to some embodiments, the PIN is not of a prescribed length,but may rather be on any length within a predetermined range, e.g.,between four and fifty-six digits. Also, where a mathematical operationis performed upon the PIN, e.g., dividing the PIN by a selectedquantity, N, it is understood that the resulting quantity may be roundedto a nearest number, or otherwise operated upon, to arrive at an integerquantity.

The cardholder may enter data into any of the fields corresponding tothe PIN modification scheme he wishes to be applied to the card(operation 1506). Example: to establish that the PIN associated with hiscard should be incremented by 5 each week, the cardholder may enter “5”into a field labeled “quantity by which to increment PIN” and “weekly”in a field labeled “period in which to increment PIN.” Finally, as shownin operation 1508, the software system of FIG. 7 associates the selectedrules with the card number entered during operation 1500.

According to another embodiment, the software system of FIG. 7 maysupport selection of a PIN that is used only once. For example, thecardholder may select a PIN that is always associated with his cardnumber (by use of a web site provided by the front end module 726, asdescribed previously). In addition to thereto, the cardholder may selecta PIN that may be used but once (again, by use of a web site provided bythe front end module 726, as described previously). When, in the contextof executing a transaction, the software system of FIG. 7 receives anencrypted transport object, such as the one of FIG. 6, the thirddecryption module 712 may initially attempt its decryption using the“ordinary” PIN, as described with reference to FIG. 7. Assuming that thedecryption fails, the third decryption module 712 attempts decryptionwith the “one-time” PIN associated with the card number. If successful,the transaction is carried out as described previously, and the one-timePIN is disabled from further use. Such a one-time PIN is useful forsettings in which the cardholder is hesitant about providing his“ordinary” PIN to a merchant, such as when the cardholder may be usingan unfamiliar e-commerce website, or when he believes that entry of hisPIN may be under observation. Since the PIN can only be used once, itdoes not matter if entry of the PIN is observed or captured by awebsite.

According to another embodiment of the invention, the aforementionedtransaction scheme may be utilized to permit inter-merchant return ofgoods, as illustrated with reference to FIGS. 16A and 16B. For example,FIG. 16A depicts a typical on-line purchasing arrangement, whereby acardholder 1600 orders an item from an on-line merchant 1602. Thecardholder 1600 receives the item from the on-line merchant (operation1601). In response, the card-issuing bank 1604 forwards the item priceto the bank of the on-line merchant (operation 1603). Then, at theexpiration of the billing period, the cardholder 1600 pays a sum ofmoney equal to the item price to the bank 1604 (operation 1605).

FIG. 16B presents one example of an inter-merchant return of goodsarrangement. Per the arrangement of FIG. 16B, the cardholder 1600returns the item to a bricks-and-mortar merchant 1606 (operation 1607).At the time of return, the cardholder 1600 presents his receipt to thebricks-and-mortar merchant 1606, who uses the information thereon toindicate to the transaction platform that a return of a particular goodfrom a particular merchant by a particular cardholder is to betransacted at a the bricks-and-mortar merchant store 1606. Using theaforementioned information, the transaction platform accesses a rulesdatabase to determine a sum of money to be transferred from thebricks-and-mortar merchant to the on-line merchant. The transactionplatform's server then initiates a transfer of funds from thebricks-and-mortar merchant's bank to the on-line merchant's bank equalto the determined sum (operation 1609). The aforementioned rule-basedsum may be agreed upon in advance by the individual merchants, and maybe a function of the particular good to be exchanged, or class of goodsto be exchanged, and may additionally be a function of the twoparticular merchants involved in the inter-merchant exchange.

Thereafter, the on-line merchant 1602 transfers a sum of money equal tothe item's price to the card-issuing bank 1604 (operation 1611), and thecard-issuing bank 1604 credits the cardholder's account with a sum ofmoney equal to the price of the item (operation 1613). Thus, thecardholder 1600 is free to conduct a purchase with one merchant (such ason-line merchant 1602), and to return the good to a second merchant(such as bricks and mortar merchant 1606). This return arrangement ismade possible, because an agreed upon sum to be transferred from onemerchant to another merchant in the event of an exchange of a particulargood or class of goods is stored at a database in communication with thetransaction platform's server.

FIG. 17 depicts a scheme wireless exchange of funds between cardholders.The scheme involves an applet that runs on a processor within a cellulartelephone. The applet includes a prompt module 1700 that asks acardholder to enter the following data: (1) the quantity of money he orshe wishes to transfer to another cardholder; (2) the cardholder's PINcode; and (3) the cellular telephone number of the recipient. Theaforementioned data is agglomerated into a data set, and is encrypted byencryption unit 1702, which may operate according to the principlesdescribed above. The encrypted data set is then communicated via the SSLInternet connection transaction platform of FIG. 7.

At the front end, the telephone number from which the transactionoriginated is extracted, and is used to query a database 1704 thatassociated cardholder telephone numbers with PIN codes. Thecorresponding PIN code is therefore returned to module 1706, and isprovided to decryption module 1708, which uses the PIN code as adecryption key.

Thereafter, the availability of funds in the account corresponding tothe PIN is checked. According to one embodiment, the PIN or telephonenumber may be used to access a database 1710 that relates a cardidentification number to a PIN or telephone number. The retrieved cardidentification code is then sent to fund check module 1712, whichdetermines whether the account corresponding with the PIN/telephonenumber has sufficient funds to permit the proposed exchange. If so, theexchange is transacted, and an SMS is sent by module 1714 to therecipient's telephone number, informing him or her of the exchange offunds.

A person-to-person exchange of funds may also be conducted on-line via aweb site presented from the front end module 726, generally proceedingas described with reference to FIG. 17.

FIG. 18 depicts one exemplary embodiment of a person-to-persontransaction, as just discussed. As shown in FIG. 18, the transactionplatform 1800 extends access to monetary funds (line of credit, debitaccount, checking account, savings account, stored value, and/orpre-paid account) through each of two banks 1802 and 1804. In principle,the platform 1800 may extend access to funds through any number ofbanks. For the sake of illustration, a person-to-person transfer of fundis described with reference to transfer from a credit card. Transfer offunds may be executed from any type of account to any type of account.Again, for the sake of illustration only, it is assumed that thetransaction platform handles eight parties, each of which own atransaction card that functions as a credit card. Four of thecardholders access a line of credit through bank 1802, while the otherfour access a line of credit through bank 1804. Thus, as shown in FIG.18, an account is maintained for each cardholder by each card-issuingbank 1802 and 1804. One such account is identified by reference numeral1806, and another such account is identified by reference numeral 1808.

Assuming that the cardholder associated with credit account 1806 wishesto transfer funds to the party associated with account 1808, such fundsmay be made instantly available to the party associated with account1808. The transaction platform maintains an account 1810 and 1812 ateach bank 1802 and 1804. All cardholders having accounts at bank 1802have the funds of their pre-paid accounts stored in account 1810, whileall cardholders having accounts at bank 1804 have the funds of theirpre-paid accounts stored in account 1812. The platform maintains adatabase 706 that keeps track of each cardholder's share of the fundsheld in the pre-paid accounts 1810 and 1812. A transfer from a creditaccount 1806 to the cardholder associated with credit account 1808 istransferred from credit account 1806 to the pre-paid account 1812, andthe database 1706 is immediately updated to: (1) reflect that theaccount 1812 is incremented by the monetary sum being transferred; and(2) reflect that the cardholder associated with credit account 1808 hasa share of the pre-paid account that is incremented by the monetary sumbeing transferred. Thus, the cardholder associated with monetary account1808 may immediately draw his portion from the pre-paid account 1812,e.g., may conduct a purchase of a good or service by transacting suchpurchase as a pre-paid transaction, meaning that the funds are withdrawnfrom that pre-paid account 1812, and the database 706 is immediatelyupdated to reflect such transaction. Alternatively, the cardholderassociated with credit account 1808 may specify that the received fundsbe transferred to his credit account 1808, or any other account. Suchtransfer is then completed, for example, at the end of the day when thedatabase 706 and the bank's 1804 computer system are synchronized, inorder to reflect that the monetary sum is to be withdrawn from thepre-paid account 1812 and deposited into the credit account 1808.

The various embodiments described above are provided by way ofillustration only and should not be construed to limit the invention.Those skilled in the art will readily recognize various modificationsand changes that may be made to the present invention without followingthe example embodiments and applications illustrated and describedherein, and without departing from the true spirit and scope of thepresent invention, which is set forth in the following claims.

1. A method comprising: associating, in a database, a transaction cardthrough which access to monetary funds is extended with non-financialinformation including health information; receiving a transactionrequest associated with the transaction card; accessing thenon-financial information associated with the transaction card; andassessing the transaction request based on the non-financialinformation.
 2. The system of claim 1, wherein the non-financialinformation includes one or more rules applied to the transaction card.3. The method of claim 2, wherein the one or more rules includes a rulesetting a maximum number of dollars per specified period of time thatmay be spent.
 4. The method of claim 2, wherein the one or more rulesincludes a rule setting types of goods or services that may be purchasedwith the transaction card.
 5. The method of claim 2, wherein the one ormore rules includes a rule specifying of one or more merchants to whichpayment from said monetary funds may not be extended.
 6. The method ofclaim 1, wherein the transaction request includes level three data. 7.The method of claim 6, further comprising authorizing at least part ofthe transaction request based on types of goods or services identifiedby the level three data.
 8. The method of claim 1, wherein the healthinformation includes information about health insurance.
 9. The methodof claim 1, further comprising extending access to the monetary fundsassociated with the transaction card.
 10. The method of claim 1, furthercomprising transferring at least a portion of the monetary funds basedon the transaction request.
 11. A system comprising: a transaction cardthrough which access to monetary funds is extended; a databaseassociating the transaction card with non-financial informationincluding health information, a computing system storing a set ofinstructions, which when executed, cause the computing system to:receive a transaction request associated with the transaction card;access the non-financial information associated with the transactioncard; and assess the transaction request based on the non-financialinformation.
 12. The system of claim 11, wherein the non-financialinformation includes one or more rules applied to the transaction card.13. The system of claim 12, wherein the one or more rules includes arule setting a maximum number of dollars per specified period of timethat may be spent.
 14. The system of claim 12, wherein the one or morerules includes a rule setting types of goods or services that may bepurchased with the transaction card.
 15. The system of claim 11, whereinthe computing system includes instructions to access one or more typesof health information based on a merchant identifier included in thetransaction request.
 16. The system of claim 11, wherein the transactionrequest includes level three data.
 17. The system of claim 11, whereinsaid computing system is programmed to limit purchases to by specifyingone or more classes of products or services that may not be purchased.18. The system of claim 11, wherein said computing system is programmedto allow specification of one or more merchants to which payment fromsaid monetary funds may not be extended.
 19. The system of claim 11,wherein the transaction card is a card selected from the groupconsisting of: a credit card; a debit card; and a stored value card. 20.The system of claim 11, wherein the health information includesinformation about health insurance.
 21. The system of claim 11, furthercomprising extending access to the monetary funds associated with thetransaction card.
 22. The system of claim 11, further comprisingtransferring at least a portion of the monetary funds based on thetransaction request.
 23. A method comprising: associating, in adatabase, a transaction card through which access to monetary funds isextended with health information via a transaction card identifier;receiving a transaction request including the transaction cardidentifier; access the health information associated with thetransaction card; and assess the transaction request based on the healthinformation.
 24. The method of claim 23, wherein the health informationincludes information about health insurance.